-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vendor tomli 1.2.3 in flit_core #492
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems fine to me!
I'm wary of how downstream debundlers will mess with things, but... eh, we can get to that when we get there.
Just a FYI, the vendored Looks good. :) |
Yup, definitely. The vendored version will stay there as long as it's needed for any supported Python version. |
This avoids the dependency cycle, and also means we don't have to special case flit_core building itself, because we can rely on having a TOML parser.
I've left a note on how it can be unbundled, but of course if people do that, they will need to deal with the dependency cycle some other way. One option would be to get flit_core and tomli installed before unbundling, another would be to make them both available without installing to use for a special bootstrapping step (like python-bootstrap does).
This should be a special case, and hopefully can go away again once there's a TOML parser in the Python standard library.
Closes #483 (I wanted to avoid the extra layers of tooling & automation that PR proposes, as this is just one package)